In the field of wireless communications, it is known to provide wireless communications devices, for example mobile communications devices, such as wireless cellular communications terminals with a baseband Integrated Circuit (IC) and a Radio Frequency (RF) IC. Specification version 3.09 from the standards working group of the Third Generation Partnership Project (3GPP) describes a so-called “DigRF 3G” interface in order to support a connection between any baseband IC and an RF IC. In particular, the DigRF 3G interface specifies a data block used to transfer data, time accurate strobes and control data between the baseband IC and the RF IC during operation of the cellular communications terminal.
Application Programming Interfaces (APIs) can be, and are, developed that support communication of commands from the baseband IC to the RF IC, the APIs requiring the development of drivers therefore. One known API, an Amplifier Output Control (AOC) API, sometimes referred to as a Power Amplifier Control (PAC) API, includes a so-called GT2 command for transmitter programming. The GT2 command is relatively complex and development of a layer 1 driver to support the AOC API is similarly complex and has to be done on a per RF IC basis in order to support particular performance characteristics of the RF IC. Development of the layer 1 driver includes derivation of a complex look-up table that is stored in non-volatile memory of the baseband IC in order to enable output power levels of a power amplifier of the RF IC to be targeted.
In an effort to reduce the complexity associated with driver development, a so-called “Smart AOC” API was designed and is employed in the RFX300-40 RF subsystem available from Freescale Semiconductors, Inc. The Smart AOC API introduces a new command, the GT1 command, for transmitter programming. The Smart AOC API has a significantly simpler payload structure than that of the GT2 command mentioned above and provides certain known benefits during use of the cellular communications terminal post-manufacture. Indeed, the simplicity of the Smart AOC API provides numerous advantages, one of the most important being speed of configuration of the transmitter and receiver of the RF IC by the baseband IC. To achieve this, a look-up table similar in nature to that derived for the GT2 command is developed and stored in non-volatile memory of the RF IC.
By way of example of the simplicity of the Smart AOC API, in order to target a predetermined output power level, for example 33 dBm, the GT2 command structure requires the baseband IC to specify a so-called AOC parameter that allows choice of efficiency trade-offs at a given power level, for example bias of the power amplifier, and a 12-bit Digital-to-Analogue Converter (DAC) word conforming to specification version 45.005 from the standards working group of 3GPP in relation to specifying power steps. In contrast, the GT1 command of the Smart AOC simply requires the baseband IC to specify a 5-bit word identifying a so-called Power Control Level (PCL) code. Of course, each of the GT1 and GT2 commands requires the baseband IC to specify other parameters, but the above two differences are most notable in the present comparison. Indeed, software engineers developing the baseband IC have less development work, because a local look-up table is no longer required. Additionally, the payload of the GT1 command has fewer parameters associated therewith as compared with the payload of the GT2 command.
However, by simplifying the baseband IC, development effort is transferred to development of the RF IC. In this respect, the GT2 command is used by developers of the layer 1 driver for the GT1 command in order to generate a look-up table for use by the RF IC locally in relation to the GT1 command. The look-up table is manually generated and so labour intensive and particular to the RF IC for which the layer 1 driver for the GT1 command is to support.
During manufacture of the wireless cellular communications terminal and prior to dispatch thereof from a manufacturing facility, it is known to calibrate the RF IC in order to ensure accurate and reliable operation of the communications terminal. If the GT2 command is to be used by a manufacturer, calibration has to be performed in respect of the GT2 command. Similarly, if the GT1 command of the Smart AOC API is to be used, calibration has to be performed in respect of the GT1 command. However, as mentioned above, in order to use the GT1 command of the Smart AOC API, it is necessary to develop the layer 1 driver for the GT1 command and this requires the layer 1 driver for the GT2 command to have been developed, i.e. two drivers have to be developed in order to be able to use the GT1 command. Consequently, if considerable effort has been expended in the development of the layer 1 driver to support the GT2 command, fewer advantages remain in respect of continuing and developing the layer 1 driver to support the GT1 command of the Smart AOC API. The GT2 command, whilst more complicated than the GT1 command, can serve the purpose of the GT1 command in many respects, the additional remaining benefits of the GT1 command of the Smart AOC API not meriting the additional development effort required to support the GT1 command. It therefore follows that, currently, it is uneconomic to develop the layer 1 driver for the GT1 command for calibration purposes, because the more complex driver for the GT2 command would, in any event, need to be developed and, in most cases, can be used for most applications.